[00:00] In this lesson, we'll learn how to create a remote tag provider. This allows gateways connected over the gateway network to share their tag data. Looking at my network diagram, we can see I already have a gateway network set up with two gateways. Ignition A is hosted locally, and ignition B is on a remote machine. Ignition B has tag data through a programmable device simulator. If we want ignition A to be able to read from or write to those tags on ignition B, then we can create a remote tag provider on ignition A. Remote tag providers are a distributed service available with a gateway network connection, so we can create one by navigating to the services tab on ignition A and clicking on the tags page. Here we can see the tag providers that come with a fresh install of ignition. Those are the default and system tag providers. To create a remote tag provider, we can click on this create tag provider button. On this page, there's two options for tag providers we can create and we'll select the remote tag provider option and click on next.

[01:10] Now we can configure the remote tag provider and there's a few requirements. First, we'll need to provide a name. I'll name this ignition B remote tags. Next, we need to identify the remote gateway and the tag provider we want to use from the remote gateway. For the gateway, this field already knows about our connected gateway ignition B, so we'll select that. I want to use ignition B'S default tag provider since that is where those simulator tags are contained. So we'll type out the word default in this field. That's all you need to do on this page when creating a remote tag provider, but I'll go over some additional options we do have access to. We'll scroll down to the history settings where we can choose the method for how tag history data is accessed. By default this is set to gateway network, meaning tag history data requests are sent across the gateway network. If the tag historian on ignition B was the database that ignition A is directly connected to, then you can also choose the database option for history access, allowing tag history to be directly queried from the database.

[02:14] The next three options here are used to identify that history data source, but since I don't have a database historian connected, I'll leave the history access set to gateway network. Below the history settings, we have alarm settings which determine how alarms are going to be handled with these tags. We do have the option to disable the alarms, but by default they are enabled. You can also choose whether alarms can be queried through the gateway network or directly subscribed to the trade off here is that when you subscribe to alarms, you'll get better system performance at the cost of more memory usage. Finally, we have some advanced settings available by expanding them here at the bottom. These determine how tag data arrives to ignition A. If you're curious about these advanced settings, I've included a link to our user manual going over them in more detail.

[03:03] After configuring a tag history provider, you then create it by clicking on the create tag provider button. We can see that ignition B remote tags was added and it's currently running. This means that ignition A now has access to all 88 of these tags on ignition B. Let's take a look at this in the designer space. On my screen now I have designers open for a project in ignition B shown on the right and ignition A shown on the left. I also have the tag browser filling out most of the screen, and we can see the tags that belong to the default tag provider on ignition B. I also wanna point out that both designers are set to full read-write communications. To see these same tags on ignition A, we simply need to switch to the tag provider from ignition A default to the remote tag provider we just created, ignition B remote tags. I'll go ahead and expand the same folder and we'll see that all of the same tags in ignition B are now represented in ignition A. With a keen eye you might notice one difference, and that's the alarm metrics section for these tags only show on ignition B.

[04:12] That's because in a gateway network, things like writing to the PLC, alarms, and history for these tags are handled in the gateway they were created in. In this case, that would be ignition B. So right now, ignition A is only able to read the tag data, so we could do something like checkoff writeable boolean one, and that change will be sent across the gateway network and be reflected on ignition A. If we try to write to the tag from ignition A, then we'll get this access denied message, and that's because we have some security settings on ignition B preventing this action. Let's go to our ignition B gateway and take a look at its security zones. Out of the box, every gateway has a default security zone, and the description here lets us know that it cannot be edited. If we try to edit the zone, everything in here will be grayed out and inaccessible, but we can see under our identifier section, which is where we can pass in remote gateway identifiers to be accepted in this zone is empty.

[05:16] You can learn more about security zones in later courses, but to allow remote connections to do things like tag writes, then you would need to create a new zone pass in the remote identifier and make sure the policies for tag rights in the zone are allowed. Below this video, I've included a link to the user manual page about creating security zones, if you want to put this in place.